home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-atm-mtu-02.txt < prev    next >
Text File  |  1993-10-26  |  12KB  |  285 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8. Network Working Group                                Randall J. Atkinson
  9. INTERNET DRAFT DRAFT                           Naval Research Laboratory
  10. <draft-ietf-atm-mtu-02.txt>                              26 October 1993
  11.  
  12.                   Default IP MTU for use over ATM AAL5
  13.  
  14. Status of this Memo
  15.  
  16.      Internet Drafts are working documents of the Internet Engineering
  17.    Task Force (IETF), its Areas, and its Working Groups.  Note that
  18.    other groups may also distribute working documents as Internet
  19.    Drafts.  This particular draft is a working document of the IETF's
  20.    "IP over ATM" working group.  It is intended to eventually submit
  21.    this draft to the IESG for possible release as a standards-track RFC.
  22.  
  23.      Internet Drafts are draft documents valid for a maximum of six
  24.    months.  This Internet Draft expires on 26 April 1994.  Internet
  25.    Drafts may be updated, replaced, or obsoleted by other documents at
  26.    any time.  It is not appropriate to use Internet Drafts as reference
  27.    material or to cite them other than as a "working draft" or "work in
  28.    progress".
  29.  
  30.      Please check the I-D abstract listing contained in each Internet
  31.    Draft directory to learn the current status of this or any other
  32.    Internet Draft.
  33.  
  34.      Distribution of this memo is unlimited.
  35.  
  36. Default Value for IP MTU over ATM AAL5
  37.  
  38.      Protocols in wide use throughout the Internet, such as the Network
  39.    File System (NFS), currently use large frame sizes.  Empirical
  40.    evidence with various applications over the Transmission Control
  41.    Protocol (TCP) indicates that larger Maximum Transmission Unit (MTU)
  42.    sizes for the Internet Protocol (IP) tend to give better performance.
  43.    Fragmentation of IP datagrams is known to be highly undesirable.
  44.    [KM87] It is desirable to reduce fragmentation in the network and
  45.    thereby enhance performance by having the IP Maximum Transmission
  46.    Unit (MTU) for AAL5 be reasonably large.  NFS defaults to an 8192
  47.    byte frame size.  Allowing for RPC/XDR, UDP, IP, and LLC headers, NFS
  48.    would prefer a default MTU of at least 8300 octets.  Routers can
  49.    sometimes perform better with larger packet sizes because most of the
  50.    performance costs in routers relate to "packets handled" rather than
  51.    "bytes transferred".  So there are a number of good reasons to have a
  52.    reasonably large default MTU value for IP over ATM AAL5.
  53.  
  54.      RFC 1209 specifies the IP MTU over SMDS to be 9180 octets, which is
  55.    larger than 8300 octets but still in the same range. [RFC-1209] There
  56.  
  57.  
  58.  
  59. Atkinson                                                        [Page 1]
  60.  
  61. Internet Draft                                           26 October 1993
  62.  
  63.  
  64.    is no good reason for the default MTU of IP over ATM AAL5 to be
  65.    different from IP over SMDS, given that they will be the same
  66.    magnitude.  Having the two be the same size will be helpful in
  67.    interoperability and will also help reduce incidence of IP
  68.    fragmentation.
  69.  
  70.      Therefore, the default MTU for IP over ATM AAL5 shall be 9180
  71.    octets.  All implementations compliant and conformant with this
  72.    specification shall support this default IP MTU value for use over
  73.    ATM AAL5.
  74.  
  75.  
  76.  
  77. Minimum Value for IP MTU over ATM AAL5
  78.  
  79.      The smallest acceptable value for the IP MTU for use over ATM AAL5
  80.    is 576 octets.  This value conforms with the requirements of the Host
  81.    Requirements RFC and is consistent with the IP specification.  [RFC-
  82.    793, RFC-1122]. All ATM Forum compliant implementations of ATM
  83.    technology are capable of handling this restriction without
  84.    difficulty.  This restriction is placed in order to minimise the
  85.    occurence for IP fragmentation, which is known to be harmful, and to
  86.    ensure support for future versions of IP that are currently in
  87.    development.  Note that this minimum MTU does not place any lower
  88.    bound on the size of the IP datagram that may be transmitted by any
  89.    system.  Rather, it ensures that all systems will handle IP datagrams
  90.    of size less than or equal to 576 octets without IP fragmentation.
  91.    Before such a small MTU value may be used, the requirements described
  92.    in the MTU NEGOTIATION section must be adhered to.
  93.  
  94.  
  95.  
  96. MTU Negotation for ATM AAL5
  97.  
  98.      The ATM signalling protocol uses two different parts of the
  99.    Information Element named "AAL Parameters" to exchange information on
  100.    the MTU over the ATM circuit being setup [ATMF93a].  The component
  101.    named "Forward Maximum CPCS-SDU Size Identifier" contains the value
  102.    over the path from the calling party to the called party.  The
  103.    component named "Backwards Maximum CPCS-SDU Size Identifier" contains
  104.    the value over the path from the called party to the calling party.
  105.    The ATM Forum specifies the valid values of this identifier as 1 to
  106.    65534 inclusive.  Not all of those values make sense in the context
  107.    of IP over ATM as is explained in the preceding section, so not all
  108.    of those values may be used by implementations of this specification.
  109.    Note that the ATM Forum's User-to-Network-Interface (UNI) signalling
  110.    permits the MTU in one direction to be different from the MTU in the
  111.    opposite direction, so the ATM information elements might have
  112.  
  113.  
  114.  
  115. Atkinson                                                        [Page 2]
  116.  
  117. Internet Draft                                           26 October 1993
  118.  
  119.  
  120.    different values on the same connection.
  121.  
  122.      Other MTU values for ATM AAL5 (i.e. other than the default value
  123.    specified above) shall not be used unless use of the other MTU value
  124.    was successfully negotiated using industry-standard ATM-specific
  125.    mechanisms (e.g. ATM Signalling Protocol) prior to being attempted.
  126.    If negotiation of the MTU value is attempted but fails, then the
  127.    default MTU value shall be used.  If either of the above cited
  128.    information elements is not present in the ATM Signalling Protocol's
  129.    "SETUP" message, then the default MTU value shall be used for each
  130.    missing value.  If the calling device erroneously sets the value of
  131.    either information element to 0, then either the default MTU value
  132.    shall be used or the party receiving the invalid value shall clear
  133.    the call with cause "Invalid Information Element Contents" being
  134.    indicated.
  135.  
  136.      If the calling party wishes to negotiate an MTU size other than the
  137.    default, it must include the "AAL Parameters" information element
  138.    with the desired values for the Maximum CPCS-SDU Size Identifier as
  139.    part of the SETUP message of the ATM signalling protocol [ATMF93b].
  140.    The value of these identifiers may range from 576 to 65535 octets in
  141.    an implementation of this specification.  If the calling party is
  142.    only willing to use the default MTU value, the Maximum CPCS-SDU
  143.    components must not be specified in the SETUP message.  The called
  144.    party will respond using the same information elements and
  145.    identifiers in its CONNECT message response [ATMF93c].
  146.  
  147.      If the called party receives a SETUP message containing a "Maximum
  148.    CPCS-SDU Size Identifier" in the "AAL Parameters" information
  149.    element, it shall handle the Maximum CPCS-SDU Size Identifier as
  150.    follows:
  151.  
  152.  
  153.        a) If it is able to accept the proposed MTU values, it shall set
  154.        the values of the Maximum CPCS-SDU Size Identifier equal to the
  155.        proposed values and include that information in its CONNECT
  156.        message responding to the original SETUP message.
  157.  
  158.        b) If it wishes a smaller MTU size than that proposed but greater
  159.        than or equal to 576, then it shall set the values of the Maximum
  160.        CPCS-SDU Size Identifier equal to the desired value in its
  161.        CONNECT message responding to the original SETUP message.
  162.  
  163.        c) If it does not wish to negotiate the MTU, it shall not include
  164.        the Maximum CPCS-SDU Size Identifiers in its CONNECT message
  165.        responding to the original SETUP message.
  166.  
  167.  
  168.  
  169.  
  170.  
  171. Atkinson                                                        [Page 3]
  172.  
  173. Internet Draft                                           26 October 1993
  174.  
  175.  
  176.      If a called endpoint receives a SETUP message containing no
  177.    "Maximum CPCS-SDU Size Identifier" in the "AAL Parameters"
  178.    information element, it shall not include such an identifier in the
  179.    CONNECT message sent in response to the original SETUP message and
  180.    the Default MTU shall be used by both parties.
  181.  
  182.      If the called endpoint incorrectly includes the "Maximum CPCS-SDU
  183.    Size Identifier" in the CONNECT messages (e.g. because the original
  184.    SETUP message did not include such information) or it sets such an
  185.    identifier to a value less than 576 or more than the value of the
  186.    original SETUP message, then the calling party shall clear the call
  187.    with cause "Invalid Information Element Contents" being indicated.
  188.  
  189.  
  190.  
  191. Path MTU Discovery Required
  192.  
  193.      The Path MTU Discovery mechanism is an Internet Standard and is an
  194.    important mechanism for reducing IP fragmentation in the Internet.
  195.    This mechanism is particularly important because new subnet
  196.    technologies, such as ATM, use default MTU sizes different from older
  197.    subnet technologies such as Ethernet and FDDI.
  198.  
  199.      In order to ensure good performance throughout the Internet and
  200.    also to permit IP to take full advantage of the potentially larger IP
  201.    datagram sizes supported by ATM, all implementations that comply or
  202.    conform with this specification must implement the IP Path MTU
  203.    Discovery mechanism as defined in RFC-1191.
  204.  
  205.  
  206.  
  207. Security Considerations
  208.  
  209.    Security Considerations are not discussed in this memo.
  210.  
  211.  
  212.  
  213. References
  214.  
  215.    [RFC-791] J. Postel, Internet Protocol, RFC-791, DDN Network
  216.    Information Center, September 1981.
  217.  
  218.    [RFC-793] J. Postel, Transmission Control Protocol, RFC-793, DDN
  219.    Network Information Center, September 1981.
  220.  
  221.    [RFC-1122] R. Braden (Ed.), Requirements for Internet Hosts --
  222.    Communications Layers, RFC-1122, DDN Network Information Center,
  223.    October 1989, pp.58-60.
  224.  
  225.  
  226.  
  227. Atkinson                                                        [Page 4]
  228.  
  229. Internet Draft                                           26 October 1993
  230.  
  231.  
  232.    [RFC-1191] J. Mogul & S. Deering, Path MTU Discovery, RFC-1191, DDN
  233.    Network Information Center, November 1990.
  234.  
  235.    [RFC-1209] D. Piscitello, D & J. Lawrence, The Transmission of IP
  236.    Datagrams over the SMDS Service, RFC-1209, DDN Network Information
  237.    Center, March 1991.
  238.  
  239.    [ATMF93a] R. Breault, J. Grace, J. Jaeger, & L. Wojnaroski(eds.), ATM
  240.    Forum User Network Interface Specification, Version 2.4 (clean),
  241.    Document 93-620R3, Section 5.4.5.5, p. 174, 5 August 1993, ATM Forum.
  242.  
  243.    [ATMF93b] R. Breault, J. Grace, J. Jaeger, & L. Wojnaroski(eds.), ATM
  244.    Forum User Network Interface Specification, Version 2.4 (clean),
  245.    Document 93-620R3, Section 5.3.1.7, p. 149-150, 5 August 1993, ATM Forum.
  246.  
  247.    [ATMF93c] R. Breault, J. Grace, J. Jaeger, & L. Wojnaroski(eds.), ATM
  248.    Forum User Network Interface Specification, Version 2.4 (clean),
  249.    Document 93-620R3, Section 5.3.1.3, p. 146, 5 August 1993, ATM Forum.
  250.  
  251.    [KM87] C. Kent & J.Mogul, "Fragmentation Considered Harmful", Proceedings
  252.    of the ACM SIGCOMM '87 Workshop on Frontiers in Computer Communications
  253.    Technology, August 1987.
  254.  
  255. Disclaimer
  256.  
  257.      Author's organisation provided for identification purposes only.
  258.    This document presents the author's views and is not necessarily the
  259.    official opinion of his employer.
  260.  
  261. Author Information
  262.  
  263.    Randall J. Atkinson     <atkinson@itd.nrl.navy.mil>
  264.  
  265.    Information Technology Division
  266.    Naval Research Laboratory
  267.    Washington, DC 20375-5320
  268.    USA
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283. Atkinson                                                        [Page 5]
  284.  
  285.